1. Technical Field
The present disclosure relates to software testing, and more specifically to identifying test cases to be run after changes to modules of a software application.
2. Related Art
A software application is generally organized in the form of modules. Each module contains a corresponding set of instructions, which are together compiled, linked, etc., as is well known in the relevant arts. Modules are maintained in the form of source files, class files, JAR files, etc., as is also well known in the relevant arts.
There are often changes made to specific modules, with a view to meeting specific objectives. For example, during the development phase of the software application, developers may modify modules to add/modify functionality, and during maintenance phase, developers may modify modules to fix errors (referred to as bugs also) found after deployment of the software application.
It is often required to identify test cases to be run after such changes, typically to check whether the changes meet the objectives, as well as do not cause unintended consequences (e.g., create new errors, disrupting pre-existing functionality, etc.) in the operation of the software application. Each test case is designed to contain the inputs and logic to make operative specific desired portions of the corresponding modules, and to potentially check whether the output resulting from such operation satisfies a desired condition.
It is generally desirable that an optimum set of test cases be identified such that the desired checking is performed, as well as unneeded test cases are not run. Various aspects of the present invention address one or more of such requirements, as described below in further detail.
In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.